Мы уже писали про новые возможности платформы виртуализации VMware vSphere 5.1, виртуального хранилища vSphere Storage Appliance 5.1 и средства катастрофоустойчивости виртуальной инфраструктуры VMware Site Recovery Manager 5.1, которые были представлены на конференции VMworld 2012. Сегодня мы расскажем еще об одной инициативе VMware для средних и крупных предприятий - решении VMware vCloud Suite, объединяющем перечисленные выше продукты и некоторые другие.

Как мы видим из картинки, VMware vCloud Suite - это, можно сказать, многокомпонентный продукт, лицензируемый на физические процессоры хост-серверов VMware vSphere 5.1 и выше (независимо от числа ВМ), который построен на базе издания Enterprise Plus. Это именно продукт, а не пакет, так как нельзя разделять лицензии различных составляющих на процессоры разных хост-серверов ESXi или виртуальных машин. Каждая из ВМ, работающих в рамках продукта, может использовать любой из его компонентов.

Состав пакета VMware vCloud Suite (основные компоненты):

• Платформа виртуализации VMware vSphere Enterprise Plus
• Средства управления облачной инфраструктурой VMware vCloud Director и vCloud Connector
• Средства безопасности в облаке vCloud Networking and Security (с поддержкой VXLAN)
• Средство централизованного управления и мониторинга vCenter Operations Management Suite
• Средство развертывание приложений в облаке vFabric Application Director
• Средство обеспечения катастрофоустойчивости VMware SRM

Из преведенных выше продуктов незнакомым является vCloud Networking and Security (vCNS). Что это? Все просто - это еще один ребрендинг и репакаджинг семейства продуктов VMware vShield:

Что касается изданий VMware vCloud Suite, их 3 штуки: Standard, Advanced и Enterprise (кликабельно):

В издании Enterprise прибавляются еще средства vCenter Configuration Manager и vCenter Chargeback Manager.

Если у вас уже есть VMware vSphere в любом из изданий, то вы можете обновиться до vCloud Suite по специальным парт-номерам:

Если есть не только vSphere, но и, например, SRM - то можно обновиться со скидкой 90% на соответствующий компонент:

Пример преобразования существующих лицензий со скидкой:

Но самое интересное то, что пользователи VMware vSphere Enterprise Plus получают vCloud Suite Standard абсолютно бесплатно до 15 декабря 2012 года. То есть, берете и прямо сейчас получаете лицензии на SRM, vCOPs и другое:

Также до этого времени можно покупать vSphere Enterprise Plus и бесплатно получать лицензии на компоненты vCloud Suite Standard. Так что если есть желание продвинуть свою инфраструктуру - торопитесь.

Мы уже писали о возможностях новой версии платформы виртуализации VMware vSphere 5.1 и принципах ее лицензирования, однако не затрагивали важного для пользователей продукта - бесплатного VMware vSphere 5.1 Hypervisor (также известен как VMware ESXi 5.1 Free). Напомним, что в версии vSphere 5.1 компания VMware убрала ограничения по памяти виртуальных машин (vRAM) для всех коммерческих изданий VMware vSphere.

Однако это, по-сути, не касается бесплатной версии ESXi:

Бесплатный продукт VMware vSphere Hypervisor 5.1 (Free ESXi 5.1) имеет жесткое ограничение на физическую память хост-сервера ESXi в 32 ГБ. Если физическая RAM сервера превышает 32 ГБ, то бесплатный ESXi просто не будет загружаться.

При этом бесплатный сервер VMware ESXi 5.1 не ограничен по числу физических процессоров.

Что касается остальных ограничений бесплатного ESXi 5.1:

• Управление только одним хостом одновременно из vSphere Client (как и раньше)
• Отсутствие распределенных сервисов виртуализации (vMotion, HA, DRS, Storage DRS, клонирование ВМ и т.д.)
• API в режиме "только для чтения" (то есть невозможность сохранения изменений конфигурации через vCLI)
• Отстутсвие  Alarms и поддержки SNMP v3, что есть в коммерческой версии

В самом же гипервизоре ESXi 5.1 (в том числе бесплатном) появились следующие новые возможности:

• Extended Guest OS and CPU Support - полная поддержка операционных систем Windows Server 2012 и Windows 8, а также новейших процессоров AMD серии "Piledriver" и Intel серий "Ivy Bridge" и "Sandy Bridge".
• NEW Improved Security - отсутствие необходимости в общем root-аккаунте при работе с ESXi Shell. Подробности приведены в этом документе (и тут).
• NEW Improved Logging and Auditing - логирование активности пользователя в DCUI и по SSH ведется под его аккаунтом, что упрощает анализ логов.
• New virtual hardware - версия виртуального аппаратного обеспечения (Virtual Hardware) - 9. Это дает до 8 vCPU виртуальных машин, а также обновление VMware Tools без перезагрузки виртуальной машины. Кроме этого, доступны фукнции расширенной виртуализации CPU на хосте, что дает возможность запускать вложенные гипервизоры и ВМ.
• Поддержка FC-адаптеров 16 Gbps.
• Advanced I/O Device Management - новые команды для траблшутинга FC-адаптеров, а также фабрики SAN, что позволит искать проблемы на пути от HBA-адаптера до порта системы хранения.
• SSD Monitoring - возможность отслеживания характеристик функционирования SSD-накопителей через специальный SMART-плагин.

Партнеры и клиенты компании NetApp знают, что у нее есть виртуальный модуль (Virtual Appliance), который позволяет создавать общие хранилища для виртуальных машин VMware vSphere, называемый NetApp ONTAP Simulator. Это средство может предоставлять доступ виртуальных машин к дисковым ресурсам хост-сервера ESXi по протоколам iSCSI и NFS.

Теперь продукт Data ONTAP Edge доступен для всех желающих, а не только для партнеров и клиентов NetApp:

Основным вариантом использования Data ONTAP Edge компания NetApp видит его применение в удаленных офисах и филиалах организаций, которые не хотят делать больших инвестиций в дорогостоящие системы хранения данных.

Максимально поддерживаемый объем локальных хранилищ хост-серверов ESXi теперь составляет 5 ТБ вместо 20 ГБ в предыдущих версиях продукта. ONTAP Edge работает на платформе ONTAP 8.1.1 (ОС Data ONTAP-v) и требует не менее 2 vCPU для ВМ с виртуальным модулем, 4 ГБ памяти и не менее 57.5 ГБ дискового пространства. В решении поддерживается следующая функциональность, присущая оборудованию NetApp:

• Snapshots
• Replication
• Deduplication
• SnapVault
• SnapMirror
• SnapRestore
• FlexClone
• Поддержка программных интерфейсов VMware: VAAI, VACI и VADP
• Возможность интеграции с VMware SRM

В виртуальном модуле Data ONTAP Edge отсутствует следующая функциональность систем NetApp (некоторое пока):

• Поддержка LUN Fibre Channel и FCoE
• Data Compression
• RLM (Remote LAN Module)
• CFE, BIOS, shelf FW
• Multipathing
• Кластеризация виртуальных модулей хранилищ (CFO/SFO)

Поскольку данное решение не обладает функциями высокой доступности, то его пока можно использовать для тестирования и ознакомления с функциональностью продуктов NetApp. Можно также рассмотреть вариант его совместного использования с продуктами VMware VSA или StarWind iSCSI SAN, которые предоставляют функции высокой надежности и непрерывной доступности хранилищ.

Для установки Data ONTAP Edge потребуется следующая аппаратная конфигурация сервера ESXi:

• Минимум 1 процессор Quad core или 2 Dual core (64-bit Intel x86) 2.27 ГГц или быстрее
• 4 и более ГБ памяти (рекомендуется 8 ГБ и больше)
• 4 или более локальных дисков на сервере
• Сетевая карточка Gigabit Ethernet
• Аппаратный RAID с поддержкой энергонезависимого write cache

Важный момент, что для работы с виртуальным модулем NetApp не поддерживаются функции управления питанием хостов ESXi. Соответственно политику управления питанием на хосте нужно выставить как "High performance" или убедиться, что она определяется как "Not Supported".

Скачать пробную версию продукта NetApp Data ONTAP Edge на 90 дней можно по этой ссылке. Вам потребуется зарегистрироваться и ввести e-mail адрес не с публичным, а с корпоративным доменом. О том, как работать с виртуальным модулем, написано вот тут.

Мы уже немало писали о сертифицированном ФСТЭК продукте vGate R2 от компании Код Безопасности, который позволяет защитить виртуальную инфраструктуру VMware vSphere 5 с помощью политик безопасности, а также средствами защиты от несанкционированного доступа.

Одной из таких политик для хост-серверов ESXi в vGate R2 является политика безопасного удаления виртуальных машин, что подразумевает очистку виртуальных дисков VMDK на системе хранения при их удалении с тома VMFS. Это позволяет убедиться в том, что конфиденциальные данные, находившиеся на диске, будут недоступны для восстановления потенциальным злоумышленником, который, например, может находиться внутри компании и иметь доступ к содержимому томов VMFS через систему хранения данных или средства управления виртуальной инфраструктурой VMware vSphere.

Для выполнения операции надежного удаления ВМ администратор должен иметь доступ к ESXi-серверу (а именно к TCP-портам 902, 903, 443), на котором выполняется удаляемая ВМ, а также иметь привилегию "разрешено скачивать файлы виртуальных машин".

Если для удаляемой ВМ задана соответствующая политика безопасности, очистка дисков виртуальных машин выполняется автоматически. Если политика не задана, для этого может использоваться специальная утилита командной строки vmdktool.exe. Утилита также может быть полезна в том случае, если была удалена не ВМ полностью, а только какой-то ее диск.

Перед очисткой диска ВМ необходимо убедиться в отсутствии у виртуальной машины снапшотов, после чего необходимо остановить ВМ.

Далее выполняем следующую команду:

>vmdktool.exe –s esx1.local –u root –p password –v "[storage1] vm4/vm4.vmx" –d "[storage1] vm1/vm1.vmdk" –t 55

Более подробно об утилите vmdktool можно прочитать в документации по vGate R2.

Мы уже писали о новых возможностях Hyper-V 3.0 в обновленной версии серверной ОС Windows Server 2012. Как вы знаете, у этой ОС есть также бесплатное издание Hyper-V Server, которое представляет собой полнофункциональную платформу виртуализации с теми же возможностями, что есть и в Windows Server с ролью Hyper-V. О новой модели лицензирования Windows Server 2012 мы уже писали вот тут.

4 сентября платформы Microsoft Hyper-V Server 2012 стала доступна для загрузки (ISO 1.6 ГБ) и перешла в состояние General Availability (GA), согласно опубликованному ранее расписанию релизов.

Где скачать Windows Server 2012:

• 180-дневная пробная версия Windows Server 2012 (также уже сейчас доступна 90-дневная пробная версия Windows 8 Enterprise).
• Бесплатный Microsoft Hyper-V Server 2012 можно скачать по этой ссылке (нужно кликнуть ссылку на баннере).
• Доступна и версия Windows Storage Server 2012 - платформа для создания сетевых хранилищ.
• Бесплатный Microsoft Virtual Machine Converter доступен по этой ссылке (для миграции с платформ VMware).

Отличия Windows Server 2012 и Hyper-V Server 2012 (кроме того, что последний - бесплатен):

• Hyper-V Server 2012 не имеет графической консоли управления на хосте. Можно использовать сторонние утилиты, например, vtUtilities.
• Hyper-V Server 2012 может исполняться только с ролью Hyper-V (нет AD, DNS и прочих).
• Hyper-V Server 2012 не имеет прав на запущенные гостевые ОС Windows (см. лицензирование).

Бесплатный продукт Hyper-V Server 2012 удобно использовать с следующих сценариях:

• VDI-нагрузки на хосте без серверных нагрузок (только клиентские лицензии).
• Использование гостевых ОС Linux или FreeBSD.
• Использование серверных гостевых ОС, если в компании уже есть лицензии по действующему контракту с Microsoft.

Напомним также пару ресурсов, которые могут вам помочь предпочесть Hyper-V 2012 платформе VMware vSphere:

• Наше сравнение функциональных возможностей VMware vSphere 5 и инфраструктуры Microsoft Hyper-V 3.0 (Windows Server 2012 + SC VMM 2012)
• Компания Microsoft выпустила онлайн-утилиту для сравнения стоимости лицензий на инфраструктуру Hyper-V в Windows Server 2012 с VMware vSphere

Коллектив VM Guru с радостью представляет вам нового стратегического спонсора ресурса - компанию ИТ-ГРАД.

Основное направление деятельности сервис-провайдера ИТ-ГРАД – предоставление облачных услуг корпоративному сектору. Компания ИТ-ГРАД первой в России в 2009 году получила статус VMware Service Provider, который дал ей право предоставлять в аренду виртуальную инфраструктуру на базе технологий VMware – лидера в области виртуализации. По модели IaaS ИТ-ГРАД предлагает в аренду виртуальную инфраструктуру – гибкое решение для создания собственного парка виртуальных серверов (виртуального дата-центра).

Виртуальный дата-центр (vDC) является полностью изолированной и автономной инфраструктурой, позволяющей клиенту самостоятельно создавать и клонировать виртуальные машины, изменять их конфигурацию, управлять конфигурацией сети, публиковать приложения в интернет (используя персональный программный файервол). Виртуальный дата-центр характеризуется следующими параметрами:

• CPU – вычислительные мощности процессора (GHz)
• Memory – оперативная память (GB)
• Storage – дисковое пространство (GB)
• Network – сети (количество сетей и внешних IP адресов)
• VMs – максимальное число виртуальных машин внутри vDC.

Став клиентом ИТ-ГРАД, вы становитесь владельцем собственного виртуального центра обработки данных. Вы имеете возможность делать все необходимые операции, а именно:

• Самостоятельно создавать виртуальные серверы, когда они требуются.
• Изменять конфигурации уже существующих серверов за несколько минут, причем часть операций даже без остановки и перезагрузки сервера (для некоторых операционных систем).
• Включать, выключать, устанавливать ОС и приложения без участия специалистов ИТ-ГРАД. Данные операции Вы можете делать удаленно, не требуется какого-либо физического присутствия рядом с сервером.
• Делать резервные копии и сохранять состояния работающих серверов. Данные операции производятся очень быстро, просто и удобно - по аналогии работы с файлами – копирование, удаление, перемещение.
• Платить только за фактическое потребление! Нет необходимости переплачивать за простаивающие ресурсы.

Решения ИТ-ГРАД строятся на базе лидирующих в отрасли программных продуктов, таких как VMware vSphere, vCloud Director, vShield и т.п., а в качестве технической инфраструктуры используется новейшее оборудование лидирующих вендоров (HP+Cisco+NetApp).

Вы можете оставить заявку на расчет стоимости аренды виртуальных машин VMware, а также обратиться по адресу sales2010@it-grad.ru для запроса тестового доступа к инфраструктуре ИТ-ГРАД.

В большой виртуальной инфраструктуре присутствуют сотни хранилищ VMFS, созданных поверх LUN, где лежат виртуальные машины с различным уровнем требуемого сервиса и политик. Проблемы начинаются с того, что система хранения не знает о том, что на ее LUN находятся виртуальные машины. Например, синхронная репликация на уровне массива может делаться только на уровне LUN, хотя с данного тома VMFS требуется реплицировать не все ВМ, которые могут быть с различным уровнем критичности. То же самое касается снапшотов и снапклонов уровня массива...

Одновременно с анонсом новой версии платформы VMware vSphere 5.1 компания VMware объявила об обновлении средства VMware vSphere Storage Appliance 5.1 (VSA), которое позвляет организовать общее отказоустойчивое хранилище для виртуальных машин на базе локальных дисков хост-серверов VMware ESXi с использованием двух или трех узлов. О новых возможностях VSA предыдущей версии (1.0) мы уже писали вот тут, а сегодня расскажем о новых возможностях и лицензировании версии 5.1.

Итак, что нового появилось в VMware vSphere Storage Appliance 5.1:

Максимально поддерживаемые характеристики локальных хранилищ серверов ESXi теперь таковы:

3 ТБ диски

• 8 дисков до 3 ТБ каждый в конфигурации RAID 6 (без hot spare)
• 18 ТБ полезной емкости под тома VMFS-5 на 1 хост
• 27 ТБ полезной емкости на 3 хоста

2 ТБ диски

• 12 локальных дисков до 2 ТБ в конфигурации RAID 6 (без hot spare)
• 16 внешних дисков до 2 ТБ в RAID 6 (вместе с hot spare)
• VMware поддерживает максимальный размер тома VMFS-5 size до 24 ТБ на хост в VSA 5.1
• 36 ТБ полезной емкости на 3 хоста

Ранее, в VSA 1.0, установка vCenter не поддерживалась на хранилищах узлов, входящих в VSA-кластер. Теперь можно устанавливать vCenter на одно из локальных хранилищ серверов, не входящее в общее пространство VSA. В этом случае, при создании общей емкости VSA можно выставить размер общего пространства, оставив нужное место на локальном VMFS под vCenter:

Эта же возможность относится и к установке VSA на существующих хостах ESXi, где на локальных дисках уже есть виртуальные машины. Администратор сначала создает общее пространство VSA на хостах кластера, а потом с помощью Cold Migration переносит в общий том VMFS эти виртуальные машины. Освободившееся место можно присоединить к пространству VSA за счет функции увеличения емкости.

Емкость хранилищ VSA может быть увеличена на лету за счет добавления новых дисков. Можно добавить новый Extent к тому VMFS, а можно пересоздать RAID и сихнронизировать его с другим узлом кластера:

Также теперь с одного сервера vCenter можно управлять сразу несколькими кластерами VMware VSA, каждый из которых состоит из двух или трех узлов. Таких кластеров может быть до 150 штук для одного vCenter. Это хорошо подходит для организаций, имеющих распределенную инфраструктуру филиалов, где, как известно, денег на покупку общих систем хранения обычно нет (ROBO-сценарии).

Модуль VMware VSA 5.1 можно использовать для различных сценариев и всех изданий VMware vSphere 5, кроме самого низшего - Essentials:

Возможности продукта для всех изданий полностью идентичны, кроме того, что VSA for Essentials Plus не может управлять несколькими кластерами VSA, поскольку очевидно, что нужна лицензия vCenter Standard. Если же VSA 5.1 используется для Essentials Plus в конфигурации ROBO (то есть, несколько сайтов, объединенных единой точкой управления) - то так делать можно.

Кстати о лицензии на vCenter Standard - раньше для пользователей Essentials Plus она временно требовалась, когда вы заменяли один из узлов кластера. Теперь такой необходимости нет.

На эту тему можно также почитать документ "What's New in VMware vSphere Storage Appliance 5.1".

В конце прошлой недели компания StarWind Software объявила о выпуске своего флагманского продукта StarWind iSCSi SAN 6.0, предназначенного для создания двух- или треузловых отказоустойчивых кластеров хранилищ для VMware vSphere и Hyper-V.

Новые возможности StarWind iSCSI SAN 6.0:

• Возможность создания треузловых кластеров хранищ, что позволяет повысить уровень отказоустойчивости, производительности и надежности, а также более эффективно использовать дисковое пространство (RAID0 вместо RAID6). При этом все три узла являются активными и на них идет запись. По трем каналам синхронизации данные хранилищ синхронизируются между собой. Также все узлы обмениваются друг с другом сигналами доступности (Heartbeat).
• Репликация на удаленный iSCSI Target через WAN-соединение с поддержкой дедупликации в конфигурации резервирования N+1. Об этом мы подробно писали тут.
• Асинхронная репликация для дедуплицированных хранилищ. Любой iSCSI target может быть использован как хранилище назначения для репликации.
• Поддержка Scale-Out File Servers в Windows Server 2012. Подробнее об этом здесь.
• Поддержка механизмом дедупликации данных, которые удаляются с хранилищ - неиспользуемые блоки перезаписываются актуальными данными.
• Использование памяти механизмом дедупликации сократилось на 30%. Теперь необходимо 2 МБ памяти на 1 ГБ дедуплицируемого хранилища при использовании блока дедупликациии 4 КБ.
• Улучшенное управление HA-устройствами. Теперь можно добавить новый узел кластера StarWind к HA-устройству, удалить узел или переключиться между ними без необходимости заново пересоздавать HA Device.
• HA-устройство может использовать другие типы устройств StarWind для хранения данных. Это может быть дедуплицированный диск, "тонкое" устройство IBV или устройство типа DiskBridge.
• Возможность загрузки бездисковых серверов по iSCSI для хранилищ StarWind. Подробно процедура настройки этой функции описана в документе "StarWind iSCSI Boot".
• Улучшенное резервное копирование для виртуальных машин VMware ESX/ESXi.
• StarWind SMI-S agent, доступный для загрузки как отдельный компонент. Он позволяет интегрировать StarWind в инфраструктуру Systme Center Virtual Machine Manager (SC VMM), добавив StarWind Storage Provider, реализующий задачи управления таргетами и хранилищами.
• Появилась полноценная поддержка механизма ALUA, работа с которым идет через SATP-плагин VMW_SATP_ALUA (подробнее об этом тут).
• Некоторые дополнительные возможности для резервного копирования виртуальных машин на Hyper-V.
• Новый GUI для управления процессом резервного копирования (интегрирован в Management Console).
• Упрощенный процесс подключения серверов Hyper-V и ESXi.

Ну и главное, что в релизной версии появился VMware Backup Plugin для резервного копирования виртуальных машин VMware vSphere (он приобретается отдельно как дополнение).

Более подробно о новых возможностях StarWind iSCSI SAN 6.0 можно узнать на странице продукта. Сравнение изданий доступно тут, а сделать запрос на приобретение решения можно здесь.

Мы уже писали о новых возможностях VMware vSphere 5.1 - серверной платформы виртуализации, которая была анонсирована и выпущена на конференции VMowrld 2012. Вместе с выпуском обновленной версии продукта компания VMware внесла достаточно много изменений в издания и политики лицензирования продукта, так как почувствовала сильное давление со стороны основного конкурента - платформы Hyper-V в новой версии ОС Windows Server 2012 со множеством новых возможностей, по совокупности которых инфраструктура Microsoft почти не уступает VMware vSphere.

Итак, основные изменения в изданиях и лицензировании VMware vSphere 5.1:

• Полная отмена лимитов по vRAM и числу ядер для лицензии на процессор. Напомним, что ранее (в vSphere 5.0) при превышении суммарного значения сконфигурированной оперативной памяти виртуальных машин (vRAM) для лицензии на процессор определенного издания, пользователи были вынуждены докупать еще лицензий, чтобы соответствовать условиям VMware. Эта политика и раньше вызывала очень много вопросов, так как демотивировала пользователей наращивать коэффициент консолидации виртуальных машин на хостах VMware ESXi (превышаешь порог по памяти для лицензии->платишь больше), что противоречит самой идее виртуализации. Теперь этих ограничений нет, единица лицензирования - физический процессор сервера, при этом не важно сколько в нем ядер и памяти у самого сервера. Мы писали об этом тут.
• Во всех изданиях vSphere 5.1, начиная с Essentials Plus, появился виртуальный модуль vSphere Storage Appliance 5.1. Об этом продукте мы уже писали вот тут. Нужен он для создания общего хранилища под виртуальные машины, которое можно создать на базе локальных дисков серверов. Этот продукт обновился и теперь доступен для построения распределенной архитектуры кластеров хранилищ, управляемых через один vCenter.
• Издание VMware vSphere 5.1 Standard приобрело множество возможностей. К ним относятся: механизм резервного копирования vSphere Data Protection (подробнее здесь), "горячее" добавление устройств виртуальной машины Hot Add, фреймворк антивирусной защиты vShield Endpoint, возможность репликации виртуальных машин vSphere Replication, кластеры непрерывной доступности vSphere Fault Tolerance и, главное, механизм "горячей" миграции хранилищ виртуальных машин vSphere Storage vMotion.
• Издание VMware vSphere 5.1 Essentials Plus приобрело множество возможностей. К ним относятся: механизм резервного копирования vSphere Data Protection (подробнее здесь), фреймворк антивирусной защиты vShield Endpoint и возможность репликации виртуальных машин vSphere Replication.
• Важный момент: пользователи vSphere 5.0 теперь не имеют ограничений по vRAM. То есть, изменения в лицензированию имеют обратную силу.
• Издание VMware vSphere 5.1 Enterpise Plus позволяет иметь до 64 vCPU виртуальных машин.
• Доступна новая ветка издания VMware vSphere 5.1 Standard with Operations Management. Это издание включает в себя продукт vCenter Operations Management Suite Advanced, а также средство обновления гостевых ОС vCenter Protect Standard.

Как и всегда, пользователи VMware vSphere 5.0 с действующей подпиской и поддержкой (SnS) обновляются на VMware vSphere 5.1 бесплатно.

Все издания продукта VMware vCenter (Essentials, Foudation и Standard) включают в себя следующие возможности:

• Management service – централизованная консоль управления.
• Database server – сервер БД.
• Inventory service – сервис поиска по виртуальной инфраструктуре, в том числе с несколькими vCenter, а также средства кэширования запросов клиентов, что повышает производительность.
• VMware vSphere Clients - "толстая" и "тонкая" консоли администрирования (Web Client теперь основной), позволяющие управлять несколькими vCenter одновременно.
• VMware vCenter APIs and .NET Extension – интеграция vCenter со сторонними плагинами.
• vCenter Single Sign-On – возможность единовременного логина на сервер без необходимости вводить учетные данные в различных сервисах управления виртуальной инфраструктурой.

Издание Standard, помимо возможности управления неограниченным количеством хост-серверов, предоставляет следующие возможности:

• vCenter Orchestrator – средство автоматизации рабочих процессов в виртуальной инфраструктуре.
• vCenter Server Linked Mode – общее окружение для нескольких серверов vCenter Server.

Традиционная таблица сравнения функциональности изданий VMware vSphere 5.1, приобретаемых поштучно на процессор:

Сравнение возможностей	vSphere 5.1 Standard	vSphere 5.1 Enterprise	vSphere 5.1 Enterprise Plus
Компоненты продукта
Единица лицензирования	На 1 CPU	На 1 CPU	На 1 CPU
Объем vRAM	Не ограничено	Не ограничено	Не ограничено
Максимальное количество vCPU виртуальной машины	8	32	64
SUSE Linux Enterprise Server for VMware
Средство управления vCenter Server	vCenter Server Foundation  vCenter Server Standard	vCenter Server Foundation  vCenter Server Standard	vCenter Server Foundation  vCenter Server Standard
Возможности продукта
vSphere Hypervisor (платформа ESXi)
Thin Provisioning
Update Manager
Data Protection
High Availability
vMotion
vStorage APIs for Data Protection
Hot Add
vShield Zones
vShield Endpoint
Replication
Fault Tolerance
Storage vMotion
Virtual Serial Port Concentrator
Storage APIs for Array Integration
Storage APIs for Multipathing
Distributed Resources Scheduler (DRS), Distributed Power Management (DPM)
Storage I/O Control и Network I/O Control
Distributed Switch
Host Profiles и Auto Deploy
Storage DRS и Profile-Driven Storage

Традиционная таблица комплектов лицензий VMware vSphere 5.1 Essentials, VMware vSphere 5.1 Essentials Plus, VMware vSphere 5.1 Acceleration Kits:

Сравнение возможностей	Essentials Kit	Essentials Plus Kit	Standard  Acceleration Kit	Standard with Operations Management Kit	Enterprise  Acceleration Kit	Enterprise Plus  Acceleration Kit
Компоненты продукта
Средство управления vCenter Server	vCenter Server Essentials	vCenter Server  Essentials	vCenter Server Standard	vCenter Server Standard	vCenter Server Standard	vCenter Server Standard
Возможности общего хранилища на локальных дисках (Shared Storage)		vSphere Storage Appliance for Essentials Plus	vSphere Storage Appliance	vSphere Storage Appliance	vSphere Storage Appliance	vSphere Storage Appliance
Включенные лицензии в пакет	3 сервера, в каждом максимум 2 процессора	3 сервера, в каждом максимум 2 процессора	6 процессоров с возможностью докупки лицензий по процессорам	6 процессоров с возможностью докупки лицензий по процессорам	6 процессоров с возможностью докупки лицензий по процессорам	6 процессоров с возможностью докупки лицензий по процессорам
Объем vRAM на процессор	Не ограничено	Не ограничено	Не ограничено	Не ограничено	Не ограничено	Не ограничено
Максимальное количество vCPU виртуальной машины	8	8	8	8	32	64
SUSE Linux Enterprise Server for VMware
Возможности продукта
vSphere Hypervisor (платформа ESXi)
Thin Provisioning
Update Manager
vStorage APIs for Data Protection
Data Protection
High Availability
vMotion
vShield Zones
vShield Endpoint
Replication
Storage vMotion
Fault Tolerance
Hot Add
Virtual Serial Port Concentrator
Storage APIs for Array Integration
Storage APIs for Multipathing
Distributed Resources Scheduler (DRS), Distributed Power Management (DPM)
Storage I/O Control и Network I/O Control
Distributed Switch
Host Profiles и Auto Deploy
Storage DRS и Profile-Driven Storage
VMware vCenter Operations Management Suite Advanced
VMware vCenter Protect Standard

Полный обзор политик лицензирования и условий поставки VMware vSphere 5.1 приведен в документе " vSphere 5.1 Licensing, Pricing and Packaging".

Мы уже писали о недавно вышедшей обновленной бета-версии решения для создания отказоустойчивых хранилищ StarWind iSCSI SAN 6.0, где появилось множество новых возможностей, в том числе трехузловая архитектура кластеров хранилищ.

Компания StarWind выпустила краткий и понятный документ "Why 3-Way Synchronous Mirroring Is Better Than 2-Way?", где объясняются преимущества треузлового кластера StarWind iSCSI SAN перед двухузловым.

Причины, по которым желательно использоват трехузловой кластер, таковы:

1. Цена.

Если для двухузлового кластера рекомендуется дополнительный уровень отказоустойчивости на уровне RAID (например, RAID10), то вы получаете только 25% полезной емкости дисковых устройств (50% тратится на RAID и 50% остатка на поддержание синхронной копии). Для трехузлового же кластера можно обойтись RAID0, так как данные находятся на дисковых устройствах сразу трех узлов (можно использовать RAID0 или JBOD). Поэтому вы получаете 33% полезной емкости:

2. Надежность.

Очевидно, что три узла надежнее, чем два. Дополнительный уровень надежности, позволит обеспечить запросы самых критичных приложений предприятия.

К тому же, в первом случае, при выходе из строя одного из узлов, вы теряете 50% MPIO-путей, а во втором - только 33%.

3. Высокая производительность.

Когда в трехузловом кластере вы используете RAID0 - то данные с дисков читаются максимально быстро, а скорость записи ничем не уступает конфигурации с двухузловым кластером и RAID10. Кроме того, при выходе из строя узла в двухузловом кластере, кэш на втором узле очищается и переводится врежим write-through, что уменьшает производительность, а также вся система переходит в режим "degraded mode".

В случае с трехузловым кластером политики кэширования write-back сохраняются и потери производительности минимальны (приходим к обычному двухузловому кластеру).

Больше о продукте StarWind iSCSI SAN можно узнать здесь.

На конференции VMworld 2012 компания VMware анонсировала выпуск новой версии серверной платформы виртуализации VMware vSphere 5.1. В обновленной версии продукта появилось множество интересных возможностей, отражающих движение компании VMware в направлении развития облачных вычислений. В этой статье мы приведем полный список новой функциональности VMware vSphere 5.1, которая доступна пользователям уже сегодня...

На проходящем сейчас в Сан-Франциско VMworld 2012 компания VMware продемонстрировала новые горизонты производительности серверной платформы виртуализации, выжав 1 миллион операций ввода-вывода в секунду (IOPS) для одной виртуальной машины на VMware vSphere 5.1.

Для тестов использовалась следующая конфигурация:

Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: 2 x Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: 5 x QLA2532
Storage: 2 x Violin Memory 6616 Flash Memory Arrays
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Config: 4K IO size w/ 16 workers

Напомним, что на прошлом VMworld 2011 также была показана производительность в 1 миллион IOPS (300 000 для одной машины), но для хост-сервера VMware ESXi (суммарно от нескольких виртуальных машин).

Также из любопытных фактов, озвученных на VMworld 2012:

• 60% серверов уже являются виртуальными, VMware стремится к показателю 90% и более.
• Число сертифицированных специалистов VMware VCP достигло 125 тысяч.
• В VMworld 2012 приняли участие 20 000 специалистов.
• Основная концепция на ближайшее будущее - "Software-defined data center" (по аналогии с приобретенной недавно концепцией компании Nicira - Software-defined networking). Предполагается, что ключевые позиции в этой концепции займут продукты VMware vSphere, vCloud Director, vCloud Connector, Site Recovery Manager, vCenter Operations и vFabric Application Director.

Больше об облачных инициативах VMware - в самое ближайшее время.

Мы уже писали о том, что в решении номер 1 StarWind iSCSI SAN для создания отказоустойчивых хранилищ VMware vSphere, есть возможность создания дедуплицированных виртуальных дисковых устройств (и вот тут), на которых могут быть размещены виртуальные машины.

Те из вас, кто следит за обновлениями StarWind, знают, что в последних версиях продукта появилась возможность репликации дедуплицированных устройств на другой узел кластера StarWind. Причем можно использовать репликацию дисковых устройств как в локальной сети, так и через WAN-сети в целях создания DR-площадки виртуальной инфраструктуры (пока экспериментально).

27-го августа выйдет StarWind iSCSI SAN 6.0, возможно, там последняя конфигурация уже будет поддерживаться полноценно. Пока ее можно тестировать и оценивать производительность и надежность.

Ну а чтобы уже сейчас приступить к развертыванию реплицируемых дедуплицированных iSCSI-хранилищ для вашей инфраструктуры VMware vSphere, компания StarWind выпустила хороший мануал по настройке этой функции "StarWind iSCSI SAN 5.9 Beta : DD devices with replication".

Ну и будете на VMworld 2012 - заходите на стенд StarWind (номер 536) - коллеги расскажут много интересного.

Компания StarWind Software объявила о выпуске публичной бета-версии решения номер 1 для создания отказоустойчивых хранилищ для серверов VMware vSphere и Microsoft Hyper-V - StarWind iSCSI SAN 6.0.

О версии StarWind 5.9 мы уже писали, так вот она, не перетекая в релиз, превратилась в бету StarWind iSCSI SAN 6.0, чтобы выйти уже со всеми новыми возможностями в мажорном обновлении.

Новые возможности StarWind iSCSI SAN 6.0:

• Улучшенное управление HA-устройствами. Теперь можно добавить новый узел кластера StarWind к HA-устройству, удалить узел или переключиться между ними без необходимости заново пересоздавать HA Device.
• HA-устройство может использовать другие типы устройств StarWind для хранения данных. Это может быть дедуплицированный диск, "тонкое" устройство IBV или устройство типа DiskBridge.
• Асинхронная репликация для дедуплицированных хранилищ. Любой iSCSI target может быть использован как хранилище назначения для репликации.
• Возможность загрузки бездисковых серверов по iSCSI для хранилищ StarWind. Подробно процедура настройки этой функции описана в документе "StarWind iSCSI Boot".
• Улучшенное резервное копирование для виртуальных машин VMware ESX/ESXi.
• Некоторые дополнительные возможности для резервного копирования виртуальных машин на Hyper-V.
• Новый GUI для управления процессом резервного копирования (интегрирован в Management Console).
• Упрощенный процесс подключения серверов Hyper-V и ESXi.

Скачать бета-версию StarWind iSCSI SAN 6.0 можно по этой ссылке. Более подробно о новых возможностях можно прочитать на форуме.

Мы уже писали о продукте VMware vSphere Storage Appliance, который позволяет организовать отказоустойчивую инфраструктуру хранилищ на базе локальных дисков хост-серверов VMware ESXi, которые реализуют общее хранилище за счет зеркалирования томов и экспорта хранилищ хостам по протоколу NFS. Узлы ESXi с использованием VSA могут образовывать двух- или трехузловой кластер:

В случае, например, использования двухузлового кластера VSA совместно с технологией VMware Fault Tolerance, может возникнуть такая ситуация - когда Primary VM находится на хосте ESXi и использует основную копию тома с его локальных дисков. В случае сбоя этого хоста возникает двойной отказ - и виртуальной машины, которая на нем исполняется, и ее хранилища, так как оно находилось на дисках хоста. В этом случае возникает неизбежный простой ВМ до того момента, как подхватится хранилище с другого хоста и Secondary VM сможет его использовать.

В такой ситуации VMware рекомендует поступать так:

А именно: размещать хранилище защищенной FT виртуальной машины (ее виртуальные диски и файлы) на хосте, отличном от того, на котором она исполняется, т.е. на том хосте ESXi, где исполняется Secondary VM. В этом случае при любом отказе двойного сбоя не будет - всегда выживет или исполняющаяся ВМ или ее хранилище, которое подхватится Secondary VM.

В случае трехузловой конфигурации VSA можно пойти дальше: разместить Primary VM на одном узле, Secondary VM на другом, а файлы этой ВМ на третьем узле кластера VSA.

Недавно мы уже писали о том, как работает технология балансировки нагрузки на хранилища VMware Storage DRS (там же и про Profile Driven Storage). Сегодня мы посмотрим на то, как эта технология работает совместно с различными фичами дисковых массиов, а также функциями самой VMware vSphere и других продуктов VMware.

Для начала приведем простую таблицу, из которой понятно, что поддерживается, а что нет, совместно с SDRS:

Комментарии к таблице:

• Снапшоты на уровне массива - они никак не влияют на работу механизма SDRS, однако рекомендуется оставить его в ручном режиме, чтобы избежать возможных проблем при одновременном создании снапшота и перемещении виртуальных дисков.
• Дедупликация на уровне массива - полностью совместима со механизмом SDRS, однако рекомендуется ручной режим, так как, с точки зрения дедупликации, наиболее эффективно сначала применить рекомендации по миграции виртуальных дисков, а потом уже использовать дедупликацию (для большинства сценариев).
• Использование array-based auto-tiering - очевидно, что функции анализа производительности в дисковом массиве и перемещения данных по ярусам с различными характеристиками могут вступить вступить в конфликт с алгоритмами определения нагрузки в SDRS и перемещения vmdk-дисков по хранилищам на логическом уровне. Сам Storage DRS вступает в действие после 16 часов анализа нагрузки и генерирует рекомендации каждые 8 часов, в дисковом же массиве механизм перераспределения блоков по ярусам может работать по-разному: от real-time процесса в High-end массивах, до распределения каждые 24 часа в недорогих массивах. Понятно, что массиву лучше знать, какие блоки куда перемещать с точки зрения производительности физических устройств, поэтому для SDRS рекомендуется оставить выравнивание хранилищ только по заполненности томов VMFS, с отключенной I/O Metric.
• Репликация на уровне массива - полностью поддерживается со стороны SDRS, однако, в зависимости от использования метода репликации, во время применения рекомендаций SDRS виртуальные машины могут остаться в незащищенном состоянии. Поэтому рекомендуется применять эти рекомендации SDRS во время запланированного окна обслуживания хранилищ.
• VMware vSphere Storage Metro Cluster - здесь нужно избегать ситуации, когда виртуальный диск vmdk машины может уехать на другой сайт по отношению к хосту ESXi, который ее исполняет (когда используется общий Datastore Cluster хранилищ). Поэтому, а еще и потому, что распределенные кластеры могут строиться на базе технологий синхронной репликации хранилищ (см. предыдущий пункт), нужно использовать ручное применение рекомендаций SDRS.

• Поддержка VMware vSphere Site Recovery Manager - на данный момент SDRS не обнаруживает Datastore Groups в SRM, а SRM не отслеживает миграции SDRS по хранилищам. Соответственно, при миграции ВМ на другое хранилище не обновляются protection groups в SRM, как следствие - виртуальные машины оказываются незащищенными. Поэтому совместное использование этих продуктов не поддерживается со стороны VMware.
• Поддержка томов RDM - SDRS полностью поддерживает тома RDM, однако эта поддержка совершенно ничего не дает, так как в миграциях может участвовать только vmdk pointer, то есть прокси-файл виртуального диска, который занимает мало места (нет смысла балансировать по заполненности) и не генерирует никаких I/O на хранилище, где он лежит (нет смысла балансировать по I/O). Соответственно понадобиться эта поддержка может лишь на время перевода Datastore, где лежит этот файл-указатель, в режим обслуживания.
• Поддержка VMware vSphere Replication - SDRS не поддерживается в комбинации с хостовой репликацией vSphere. Это потому, что файлы *.psf, используемые для нужд репликации, не поддерживаются, а даже удаляются при миграции ВМ на другое хранилище. Вследствие этого, механизм репликации для смигрированной машины считает, что она нуждается в полной синхронизации, что вызывает ситуацию, когда репликация будет отложена, а значит существенно ухудшатся показатели RTO/RPO. Поэтому (пока) совместное использование этих функций не поддерживается.
• Поддержка VMware vSphere Snapshots - SDRS полностью поддерживает спапшоты виртуальных машин. При этом, по умолчанию, все снапшоты и виртуальные диски машины при применении рекомендаций перемещаются на другое хранилище полностью (см. левую часть картинки). Если же для дисков ВМ настроено anti-affinity rule, то они разъезжаются по разным хранилищам, однако снапшоты едут вместе со своим родительским диском (см. правую часть картинки).

• Использование тонких дисков VMware vSphere - полностью поддерживается SDRS, при этом учитывается реально потребляемое дисковое пространство, а не заданный в конфигурации ВМ объем виртуального диска. Также SDRS учитывает и темпы роста тонкого виртуального диска - если он в течение последующих 30 часов может заполнить хранилище до порогового значения, то такая рекомендация показана и применена не будет.
• Технология Linked Clones - не поддерживается со стороны SDRS, так как этот механизм не отслеживает взаимосвязи между дисками родительской и дочерних машин, а при их перемещении между хранилищами - они будут разорваны. Это же значит, что SDRS не поддерживается совместно с продуктом VMware View.
• Использование с VMware vCloud Director - пока не поддерживается из-за проблем с размещением объектов vApp в кластере хранилищ.
• Хосты с версией ПО, младше чем vSphere 5.0 - если один из таких хостов поключен к тому VMFS, то для него SDRS работать не будет. Причина очевидна - хосты до ESXi 5.0 не знали о том, что будет такая функция как SDRS.

Больше подробностей приведено в документе "VMware vSphere Storage DRS Interoperability".

Продолжаем вас знакомить с продуктом номер 1 StarWind iSCSI SAN, который удобно и просто использовать для создания отказоустойчивых хранилищ виртуальных машин VMware vSphere, Microsoft Hyper-V и Citrix XenServer. Так уж получилось, что мы рассказывали об использовании этого продукта на платформах VMware и Microsoft, а вот для XenServer от Citrix почти ничего не писали.

На эту тему можно порекомендовать несколько статей от sysadminlab.net, где на примере вот такой простецкой инсталляции:

рассматриваются основные аспекты применения продукта для создания iSCSI-хранилищ под виртуальные машины:

• Using Starwind iscsi storage for Xenserver. Part 1, Installing and basic setup.
• Using Starwind iscsi storage for Xenserver. Part 2, Thin Provisioning.
• Using Starwind iscsi storage for Xenserver. Part 3, Creating a pool from command-line.

Также есть небольшой сырой тест производительности в сравнении StarWind iSCSI и NFS.

Ну и документ от самой компании StarWind:

Совсем недавно мы писали про программно-определяемые сети (Software-defined networking, SDN), концепцию которых продвигала компания Nicira, которая уже скоро стенет частью VMware. Продукт компании Nicira, Network Virtualization Platform (NVP) позволяет создать единый виртуальный пул сетевых ресурсов, полученный за счет логического объединения сетевых коммутаторов и интерефейсов датацентра средствами специализированного программного обеспечения.

На этой неделе компания Oracle сделала ответный шаг на действия VMware по приобретению Nicira: Oracle приобретает компанию Xsigo Systems, занимающуюся технологиями виртуализации сетевой инфраструктуры и, как заявлено, теми же самыми программно-определяемыми сетям, что и Nicira (однако ниже мы покажем, что это не совсем так). Сумма проводимой сделки не разглашается, однако, очевидно, что это достаточно крупная сделка, учитывая известность компании в данном сегменте и перспективность этой фундаментальной технологии.

Давайте посмотрим видео Xsigo о том, как работает их технология сетевой виртуализации в флагманском продукте Data Center Fabric:

Продукт Xsigo Systems призван решать те же проблемы, что и Nicira NVP. В условиях виртуализации сетей и хранилищ развертывание новой виртуальной машины происходит за считанные минуты, а вот настройка сетевого взаимодействия, VLAN'ов безопасности и политик в различных сегментах сети предприятия занимает часы и дни. Решая эту проблему, продукт Data Center Fabric позволяет объединить сетевые ресурсы в единый пул и подключать виртуальные машины к нужным политикам и портам коммутаторов в несколько кликов. Все это особенно актуально для облачных провайдеров, имеющих в своем облаке десятки и сотни различных компаний, развертывающих свои виртуальные машины в собственной сетевой среде.

Поскольку из ролика как всегда непонятно, как это работает, приведем отзывы некоторых источников о том, что такое Xsigo DCF. Например, Wired пишет, что DCF - это продукт попроще, чем NVP от Nicira, и предназначен он для виртуализации ввода-вывода (I/O Virtualization) при подключении оконечного оборудования вроде HP Virtual Connect:

Although comparisons with VMware’s $1.26 billion acquisition of Nicira are inevitable, Xsigo actually makes a very different type of product. Whereas Nicira offers a tool that lets you build entire computer networks using nothing but software, Xsigo sells a simpler product called Data Centre Fabric (DCF), which is specifically designed to virtualize network cards and connections, reducing the amount of physical hardware and network cabling required to run a network of virtual machines.

....

This reduces both the amount of physical networking hardware required and the amount of cabling required. DCF is more comparable to HP’s Virtual Connect product. But Virtual Connect only works with HP hardware and DCF works with servers and hardware from multiple vendors.

Кстати, у Xsigo используется такое программно-аппаратное решение, которое находится "On top of the rack", агрегирующее сетевые интерфейсы оборудования и называющееся Xsigo I/O Director (сейчас он называется Fabric Diector):

Как мы видим, I/O Director соединяется с серверами по технологии 10G Ethernet или Infiniband. Отмечается также, что продукт Xsigo не требует использования виртуальных сетей VLAN для изоляции трафика виртуальных машин. При этом DCF не поддерживает технологию OpenFlow. На данный момент Xsigo DCF поддерживает аж пять гипервизоров (очевидно, поддержка должна быть на уровне виртуальных коммутаторов для платформы виртуализации): VMware vSphere, Citrix XenServer, Microsoft Hyper-V, Oracle VM Server и Red Hat Enterprise Virtualization.

Есть и другие мнения о том, чем за последние полгода стало решение Xsigo DCF:

Xsigo is the real SDN solution, it allows you to spin up connectivity from any server to any server on the fly in software and scales to thousands of servers. Nicira is nothing more than a tunneling technology inside legacy 30 year old switching technology, it doesn't solve the latency or speed requirements for today's datacenter nor the dynamic configuration requirements. Nicira and other openflow technologies are nothing more than a stop gap solution to get around configuring many different switch layers.

Однако большинство склоняется, все-таки, к тому, что DCF-это не SDN-решение, а более нишевая технлогия, направленная на уменьшение количества соединений и упрощения процедур реконфигурации программного и аппаратного обеспечения в случае изменений в сети (например, при изменении хранилища с FC на iSCSI).

Управление виртуальными сетями и соединениями производится из центральной консоли Xsigo Fabric Manager, который управляет виртуальными ресурсами, сетями, QoS и имеет шаблоны соеднинений для сетей виртуальных машин:

В составе решения есть также компоненты Xsigo Storage Accelerator и Performance Monitor:

Есть также и модная управлялка Xsigo XMS 3.0 для iPad:

Чуть более подробно о решении Xsigo можно прочитать в статье "Under the Hood with the Data Center Fabric".

Как знают многие администраторы, в новой версии операционной системы Windows Server 2012 появилась возможность использования технологии Scale-Out File Servers (SOFS) для создания кластеров SMBv3.0-хранилищ типа active/active, предоставляющих надежное и отказоустойчивое файловое хранилище различным приложениям. В частности, SOFS может быть использовано для создания общего хранилища виртуальных машин серверов Microsoft Hyper-V на базе кластерной системы CSV (Cluster Shared Volumes):

Как видно из картинки, для организации инфраструктуры SOFS нам потребуется общее хранилище, построенное на базе Fibre Channel / iSCSI / SAS, что требует дополнительных затрат на оборудование, его настройку и обслуживание.

Компания StarWind предлагает организовать общее хранилище для SOFS на базе программного решения StarWind iSCSI SAN, которое позволяет организовывать кластеры отказоустойчивых хранилищ, предоставляющих общее хранилище для виртуальных машин VMware vSphere и Microsoft Hyper-V. StarWind предлагает использовать следующую схему для размещения виртуальных машин на SOFS:

О том, как работает такая инфраструктура, и как настроить ее, читайте в новых документах компании StarWind:

Providing HA Shared Storage for Scale-Out File Servers
Configuring HA Shared Storage on Scale-Out File Servers

Как оказалось у нас на сайте нет инструкции по подключению локальных дисков сервера VMware ESXi в качестве RDM-дисков для виртуальных машин. Восполняем этот пробел. Как известно, если вы попытаетесь добавить локальный диск сервере ESXi в качестве RDM-тома для ВМ, вы там его не увидите:

Связано это с тем, что VMware не хочет заморачиваться с поддержкой дисков различных производителей, где будут размещены производственные виртуальные машины. Поэтому нам нужно создать маппинг-файл VMDK на локальное дисковое устройство, который уже как диск (pRDM или vRDM) подключить к виртуальной машине.

Для начала найдем имя устройства локального SATA-диска в списке устройств ESXi. Для этого перейдем в соответствующую директорию командой:

# cd /dev/disks

И просмотрим имеющиеся диски:

# ls -l

Нас интересуют те диски, что выделены красным, где вам необходимо найти свой и скопировать его имя, вроде t10.ATA___....__WD2DWCAVU0477582.

Далее переходим в папку с виртуальной машиной, которой мы хотим подцепить диск, например:

# cd /vmfs/volumes/datastore1/<vm name>

И создаем там маппинг VMDK-диск для создания RDM-тома, при этом можно выбрать один из режимов совместимости:

Для pRDM (Physical RDM):

# vmkfstools -z /vmfs/devices/disks/<имя t10.ATAитп> rdm_WD2DWCAVU0477582.vmdk

Для vRDM (Virtual RDM):

# vmkfstools -r /vmfs/devices/disks/<имя t10.ATAитп> rdm_WD2DWCAVU0477582.vmdk

После того, как vmdk mapping file создан, можно цеплять этот диск к виртуальной машине через Add Virtual Disk (лучше использовать для него отдельный SCSI Controller):

Второй способ, который работает не для всех дисков - это отключение фильтра на RDM-диски (это можно сделать и на сервере VMware vCenter). Для этого в vSphere Client для хоста ESXi нужно пойти сюда:

Configuration > Software > Advanced Settings > RdmFilter

Там и выставляется соответствующая галочка:

Однако, повторимся, этот метод (в отличие от первого) работает не всегда. Ну и учитывайте, что подобная конфигурация не поддерживается со стороны VMware, хотя и работает.

Мы уже писали о том, что такое и как работает технология VMware vStorage API for Array Integration (VAAI) (а также немного тут), которая позволяет передать операции по работе с хранилищами, которые выполняет компонент Data Mover в VMkernel, на сторону дискового массива. Это существенно улучшает показатели производительности различных операций (клонирования и развертывания ВМ, использования блокировок) за счет того, что они выполняются самим массивом, без задействования сервера VMware ESXi:

Если ваш массив не поддерживает примитивы VAAI, то чтобы склонировать виртуальный диск VMDK размером 64 ГБ, компонент Data Mover реализует эту операцию следующим образом:

• Разделяет диск 64 ГБ на малые порции размером в 32 МБ.
• Эту порцию 32 МБ Data Mover разделяет еще на маленькие операции ввода-вывода (I/O) размером в 64 КБ, которые идут в 32 параллельных потока одновремнно.
• Соответственно, чтобы передать 32 МБ, Data Mover выполняет 512 операций ввода вывода (I/Os) по 64 КБ.

Если же массив поддерживает примитив XCOPY (он же Hardware Offloaded Copy и SAN Data Copy Offloading), то для передачи тех же 32 МБ будут использованы I/O размером в 4 МБ, а таких I/O будет, соответственно, всего 8 штук - разница очевидна.

Интересно, как работает VAAI с точки зрения ошибок при передаче данных: например, мы делаем клонирование ВМ на массиве с поддержкой VAAI, и вдруг возникает какая-то ошибка. В этом случае VMkernel Data Mover подхватывает операцию клонирования с того места, где VAAI вызвал ошибку, и производит "доклонирование" виртуальной машины. Далее ESXi периодически будет пробовать снова использовать VAAI на случай, если это была кратковременная ошибка массива.

При этом проверки в разных версиях ESXi будут производиться по-разному:

• Для ESX/ESXi 4.1 проверка будет производиться каждые 512 ГБ передаваемых данных. Посмотреть этот параметр можно следующей командой:

# esxcfg-advcfg -g /DataMover/HardwareAcceleratedMoveFrequency
Value of HardwareAcceleratedMoveFrequency is 16384

Это значение частоты 16384 нужно умножить на порцию 32 МБ и мы получим 512 ГБ. Чтобы поменять эту частоту, можно использовать команду:

# esxcfg-advcfg -s <новое значение> /DataMover/HardwareAcceleratedMoveFrequency

• Для ESXi 5.0 и выше все проще - проверка производится каждые 5 минут.

Помимо описанных в нашей статье примитивов Full Copy, Zero Block и ATS, начиная с версии ESXi 5.0, поддерживаются еще 2 примитива:

• Thin Provisioning - механизм сообщения хостом ESXi дисковому массиву о том, что виртуальная машина или ее файлы с Thin LUN были удалены или перемещены (в силу разных причин - Storage vMotion, консолидация снапшотов и так далее), поэтому массив может забрать это дисковое пространство себе назад.
• Block Delete (UNMAP) - собственно, сам механизм забирания массивом назад дискового пространства через функции SCSI Unmap. Поддерживается с vSphere 5.0 Update 1, так как раньше с этим примитивом были проблемы. Более подробно об этом механизме можно прочитать в KB 2014849, а также в статье "VAAI Thin Provisioning Block Reclaim/UNMAP In Action".

С точки зрения дисковых массивов, работающих на NFS (прежде всего, NetApp) в ESXi 5.0 также появилась поддержка примитивов VAAI:

• Full File Clone – аналог функций Full Copy для VAAI на блочных хранилищах, предназначен для клонирования файлов виртуальных дисков VMDK.
• Native Snapshot Support – передача на сторону массива функций создания снапшота ВМ.
• Extended Statistics – включает возможность просмотра информации об использовании дискового пространства на NAS-хранилище, что полезно для Thin Provisioning.
• Reserve Space – включает возможность создания виртуальных дисков типа "thick" (фиксированного размера) на NAS-хранилищах (ранее поддерживались только Thin-диски).

Функции VAAI включены по умолчанию и будут использованы тогда, когда станут доступны (например, при обновлении Firmware дискового массива, которое поддерживает VAAI).

Многие интересующиеся значимыми событиями, происходящими на рынке виртуализации, уже, наверное, читали о том, что VMware приобрела компанию Nicira за 1,26 миллиарда долларов (из них $1,05 млрд. - кэшем, что весьма много). Сумма этой сделки заставляет обратить на нее внимание и задуматься над тем, как ведущие компании в сфере облачных вычислений видят себе будущее частных облаков.

Для начала небольшой видео-обзор решения Nicira (основной продукт компании - Nicira Network Virtualization Platform ):

Из ролика ничего не понятно - это неудивительно, поскольку технология эта фундаментальная и весьма непростая. Начнем с проблемы, которая существует в крупных компаниях по всему миру, использующих технологии виртуализации на платформе VMware vSphere. Крутые и большие организации уже давно видят виртуализацию не только как платформу, но и как основу существования облаков в контексте абстракции вычислительных ресурсов:

Основа данной концепции такова: мы берем различное железо и хранилища, которые есть в нашем датацентре, объединяем их в общий пул с помощью платформы виртуализации серверов. Далее эти вычислительные мощности и стораджи мы отделяем от логической ценностной единицы ИТ - приложений - с помощью абстракций - виртуальных машин и виртуальных хранилищ. Общий вычислительный пул датацентра мы разрезаем на логически удобные нам единицы (пулы ресурсов) и дальше предоставляем пользователям виртуальные машины с соответствующим уровнем SLA из абстрактных сущностей, которые построены поверх оборудования и вычислительной архитектуры с определенными характеристиками. Делается это с помощью VMware vCloud Director с его концепцией виртуальных датацентров:

Но, помимо абстракции вычислительных ресурсов, нам нужно еще абстрагировать и сервисы хранения. Для этого сегодня существуют техники профилирования хранилищ (Storage Profiles) и средства автоматической балансировки нагрузки на них (Storage DRS):

Следующий аспект: виртуальные машины существуют на серверах и хранилищах уже на логическом, а не на физическом уровне (независимо от вендоров железа), как сделать так, чтобы в датацентре они были защищены политиками, да и сам периметр датацентра тоже был защищен? Ответ прост - есть семейство продуктов VMware vShield:

Прекрасно. Вроде все? Нет, не все. Невиртуализованной у нас осталась еще одна часть, а именно - сети. VMware предоставляет нам распределенный виртуальный коммутатор (Distributed vSwitch) с базовыми технологиями изоляции и контроля (Private VLAN), есть также продукт от Cisco - Nexus 1000V, который выполняет схожие функции, но обладает более широкими возможностями. Все это делается на уровне абстракции сетевых интерфейсов хост-серверов.

Однако в данном подходе нет самого главного - средств абстракции и виртуализации физического сетевого оборудования (коммутаторов, маршрутизаторов), большим парком которых применительно к виртуальным машинам нужно централизованно управлять в датацентре компании, где есть сотни виртуальных сетей, политик и конфигураций. Все это приводит к тому, что на развертывание новой виртуальной машины уходит 2-3 минуты (на сервере+хранилище), а вот на настройку сетевого взаимодействия, VLAN, безопасности, политик и прочего в забюрократизированных организациях уходит несколько дней.

Вот эту фундаментальную проблему и решает компания Nicira, так недешево доставшаяся VMware:

Суть концепции Nicira применительно к сетевому взаимодействию та же самая, что и в серверной виртуализации: собираем весь набор сетевого оборудования разных вендоров в единый пул, где уже на логическом уровне определяем виртуальные сети и политики, после чего можем цеплять их к виртуальным машинам централизованно:

Все это называется программно-определяемые сети (Software-defined networking, SDN) и работает на базе программных решений, разрабатываемых Nicira с далекого 2007 года. Интересно, что основательница VMware, Диана Грин, которую двинули с поста CEO компании, была одним из инвесторов Nicira, о чем мы писали 2 года назад. Диана вышла с неплохим профитом, а Nicira теперь позволит VMware получить законченную концепцию полной виртуализации облачного датацентра. Как нам и обещали, VMware вполне может стать "VMware of Networking". Кстати, теперь при покупке Nicira компания VMware снова двигает своего CEO.

Если тема вам интересна, можно почитать следующие материалы:

• VMware and Nicira – Advancing the Software-Defined Datacenter
• VMware acquires DynamicOps and Nicira, first steps to a heterogeneous hypervisor cloud solution?
• VMware buys Nicira for $1.05 billion (Zdnet)
• What Is Network Virtualization?
• vSwitch is the New Battleground. What Every Datacenter Operator Must Know.

Ну и следующая новость - покупка компанией VMware конторы DynamicOps (продукт Virtual Resource Manager, VRM). Эта контора была выделена из небезызвестного банка Credit Suisse и разрабатывает средства для автоматизации гибридных облаков на базе нескольких гипервизоров (что неизбежно будет в крупных организациях с приходом Hyper-V 3.0), а также средства управления сервисными архитектурами вроде Platform-as-a-Service, Database-as-a-Service и Storage-as-a-Service.

Kenny сделал хорошую запись о списке дефолтных аккаунтов для различных продуктов VMware, а мы сведем это в таблицу для вашего удобства, добавив парочку отсутствующих продуктов:

Вроде всё. Если знаете еще что-то, напишите, пожалуйста, в каменты.

Мы уже касались некоторых аспектов мониторинга производительности с помощью утилиты esxtop, которая есть на сервере VMware ESXi, а также метрик производительности хранилищ (и немного сетевого взаимодействия). Сегодня мы более детально взглянем на метрики производительности процессора (CPU) для контроля нагрузки виртуальных машин.

Если мы запустим утилиту esxtop, то увидим следующие столбцы (интересующее нас выделено красным):

Нас интересует 5 счетчиков, касающиеся процессоров виртуальных машин, с помощью которых мы сможем сделать выводы об их производительности. Рассмотрим их подробнее:

Счетчик %RUN

Этот счетчик отображает процент времени, в течение которого виртуальная машина исполнялась в системе. Когда этот счетчик для ВМ около нуля или принимает небольшие значение - то с производительностью процессора все в порядке (при большом его значении для idle). Однако бывает так, что он небольшой, а виртуальная машина тормозит. Это значит, что она заблокирована планировщиком ESXi или ей не выделяется процессорного времени в связи с острой нехваткой процессорных ресурсов на сервере ESXi. В этом случае надо смотреть на другие счетчики (%WAIT, %RDY и %CSTP).

Если значение данного счетчика равно <Число vCPU машины> x 100%, это значит, что в гостевой ОС виртуальной машины процессы загрузили все доступные процессорные ресурсы ее vCPU. То есть необходимо зайти внутрь ВМ и исследовать проблему.

Счетчики %WAIT и %VMWAIT

Счетчик %WAIT отображает процент времени, которое виртуальная машина ждала, пока ядро ESXi (VMkernel) выполняло какие-то операции, перед тем, как она смогла продолжить выполнение операций. Если значение этого счетчика значительно больше значений %RUN, %RDY и %CSTP, это значит, что виртуальная машина дожидается окончания какой-то операции в VMkernel, например, ввода-вывода с хранилищем. В этом случае значение счетчика %SYS, показывающего загрузку системных ресурсов хоста ESXi, будет значительно выше значения %RUN.

Когда вы видите высокое значение данного счетчика, это значит, что нужно посмотреть на производительность хранилища виртуальной машины, а также на остальные периферийные устройства виртуального "железа". Зачастую, примонтированный ISO-образ, которого больше нет на хранилище, вызывает высокое значение счетчика. Это же касается примонтированных USB-флешек и других устройств ВМ.

Не надо пугаться высокого значения %WAIT, так как оно включает в себя счетчик %IDLE, который отображает простой виртуальной машины. А вот значение счетчика %VMWAIT - уже более реальная метрика, так как не включает в себя %IDLE, но включает счетчик %SWPWT (виртуальная машина ждет, пока засвопированные таблицы будут прочитаны с диска; возможная причина - memory overcommitment). Таким образом, нужно обращать внимание на счетчик %VMWAIT. К тому же, счетчик %WAIT представляет собой сумму метрик различных сущностей процесса виртуальной машины:

Счетчик %RDY

Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready to run), но ожидает в очереди, пока процессоры сервера ESXi заняты другой задачей (например, другой ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU). Обращать внимание на него надо, когда он превышает пороговое значение 10%.

По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение:

• сильная нагрузка на физические процессоры из-за большого количества виртуальных машин и нагрузок в них (здесь просто надо уменьшать нагрузку)
• большое количество vCPU у конкретной машины. Ведь виртуальные процессоры машин на VMware ESX работают так: если у виртуальной машины 4 vCPU, а на хосте всего 2 физических pCPU, то одна распараллеленная операция (средствами ОС) будет исполняться за в два раза дольший срок. Естественно, 4 и более vCPU для виртуальной машины может привести к существенным задержкам в гостевой ОС и высокому значению CPU Ready. Кроме того, в некоторых случаях нужен co-sheduling нескольких виртуальных vCPU (см. комментарии к статье), когда должны быть свободны столько же pCPU, это, соответственно, тоже вызывает задержки (с каждым vCPU ассоциирован pCPU). В этом случае необходимо смотреть значение счетчика %CSTP

Кроме того, значение счетчика %RDY может быть высоким при установленном значении CPU Limit в настройках виртуальной машины или пула ресурсов (в этом случае посмотрите счетчик %MLMTD, который при значении больше 0, скорее всего, говорит о достижении лимита). Также посмотрите вот этот документ VMware.

Счетчик %CSTP

Этот счетчик отображает процент времени, когда виртуальная машина готова исполнять команды, одна вынуждена ждать освобождения нескольких vCPU при использовании vSMP для одновременного исполнения операций. Например, когда на хосте ESXi много виртуальных машин с четырьмя vCPU, а на самом хосте всего 4 pCPU могут возникать такие ситуации с простоем виртуальных машин для ожидания освобождения процессоров. В этом случае надо либо перенести машины на другие хосты ESXi, либо уменьшить у них число vCPU.

В итоге мы получаем следующую формулу (она верна для одного из World ID одной виртуальной машины)

%WAIT + %RDY + %CSTP + %RUN = 100%

То есть, виртуальная машина либо простаивает и ждет сервер ESXi (%WAIT), либо готова исполнять команды, но процессор занят (%RDY), либо ожидает освобождения нескольких процессоров одновременно (%CSTP), либо, собственно, исполняется (%RUN).

Мы уже много писали о производительности решения номер 1 StarWind iSCSI SAN, которое необходимо для создания отказоустойчивых хранилищ iSCSI для серверов VMware vSphere и Microsoft Hyper-V. Сегодня мы хотим обратить внимание на один интересный документ "StarWind Deduplication vs Nexenta Deduplication Test Report", в котором рассматриваются аспекты производительности хранилищ в сравнении продуктов StarWind iSCSI SAN и NexentaStor Enterprise:

Конфигурация тестовой лаборатории:

Решение StarWind iSCSI SAN побеждает во всех категориях:

Но самое интересное это то, что решение NexentaStor на практике часто не работает (!):

Такие вот бывают продукты :)

Мы уже не раз писали о различных типах очередей ввода-вывода, присутствующих на различных уровнях в VMware vSphere, в частности, в статье "Глубина очереди (Queue Depth) и адаптивный алгоритм управления очередью в VMware vSphere". Недавно на блогах компании VMware появился хороший пост, упорядочивающий знания об очередях ввода-вывода на различных уровнях виртуальной инфраструктуры.

Если речь идет о виртуальных машинах на сервере VMware ESXi, работающих с дисковым массивом, можно выделить 5 видов очередей:

• GQLEN (Guest Queue) - этот вид очередей включает в себя различные очереди, существующие на уровне гостевой ОС. К нему можно отнести очереди конкретного приложения, очереди драйверов дисковых устройств в гостевой ОС и т.п.
• WQLEN (World Queue/ Per VM Queue) - это очередь, существующая для экземпляра виртуальной машины (с соответствующим World ID), которая ограничивает единовременное число операций ввода-вывода (IOs), передаваемое ей.
• AQLEN (Adapter Queue) - очередь, ограничивающая одновременное количество обрабатываемых на одном HBA-адаптере хоста ESXi команд ввода вывода.
• DQLEN (Device Queue / Per LUN Queue) - это очередь, ограничивающая максимальное количество операций ввода-вывода от хоста ESXi к одному LUN (Datastore).
• SQLEN (Storage Array Queue) - очередь порта дискового массива (Storage Processor, SP)

Эти очереди можно выстроить в иерархию, которая отражает, на каком уровне они вступают в действие:

Очереди GQLEN бывают разные и не относятся к стеку виртуализации VMware ESXi, поэтому мы рассматривать их не будем. Очереди SQLEN мы уже частично касались тут и тут. Если до SP дискового массива со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (SQLEN) должна удовлетворять следующему соотношению:

SQLEN>= Q*L

где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.

Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:

SQLEN>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.

Теперь рассмотрим 3 оставшиеся типа очередей, которые имеют непосредственное отношение к хосту VMware ESXi:

Как мы видим из картинки - очереди на различных уровнях ограничивают число I/O, которые могут быть одновременно обработаны на различных сущностях:

• Длина очереди WQLEN по умолчанию ограничена значением 32, что не позволяет виртуальной машине выполнять более 32-х I/O одновременно.
• Длина очереди AQLEN - ограничена значением 1024, чтобы собирать в себя I/O от всех виртуальных машин хоста.
• Длина очереди DQLEN - ограничена значением 30 или 32, что не позволяет "выедать" одному хосту ESXi с одного хранилища (LUN) более 30-ти или 32-х операций ввода-вывода

Все эти очереди можно посмотреть с помощью esxtop:

Зачем вообще нужны очереди? Очень просто - очередь это естественный способ ограничить использование общего ресурса. То есть одна виртуальная машина не заполонит своими командами ввода-вывода весь HBA-адаптер, а один хост ESXi не съест всю производительность у одного Datastore (LUN), так как ограничен всего 32-мя I/O к нему.

Мы уже писали о функционале Storage I/O Control (SIOC), который позволяет регулировать последний тип очереди, а именно DQLEN, что позволяет корректно распределить нагрузку на СХД между сервисами в виртуальных машинах в соответствии с их параметрами shares (эта функциональность есть только в издании vSphere Enterprise Plus). Механизм Storage IO Control для хостов VMware ESX включается при превышении порога latency для тома VMFS, определяемого пользователем. Однако, стоит помнить, что механизм SIOC действует лишь в пределах максимально определенного значения очереди, то есть по умолчанию не может выйти за пределы 32 IO на LUN от одного хоста.

Для большинства случаев этого достаточно, однако иногда требуется изменить обозначенные выше длины очередей, чтобы удовлетворить требования задач в ВМ, которые генерируют большую нагрузку на подсистему ввода-вывода. Делается это следующими способами:

1. Настройка длины очереди WQLEN.

Значение по умолчанию - 32. Его задание описано в статье KB 1268. В Advanced Settings хоста ESXi нужно определить следующий параметр:

Disk.SchedNumReqOutstanding (DSNRO)

Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN от хоста ESXi (это глобальная для него настройка). То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в случае, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32.

2. Настройка длины очереди AQLEN.

Как правило, этот параметр менять не требуется, потому что дефолтного значения 1024 хватает практически для всех ситуаций. Где его менять, я не знаю, поэтому если знаете вы - можете написать об этом в комментариях.

3. Настройка длины очереди DQLEN.

Настройка этого параметра описана в KB 1267 (мы тоже про это писали) - она зависит от модели и драйвера HBA-адаптера (в KB информация актуальна на июнь 2010 года). Она взаимосвязана с настройкой Disk.SchedNumReqOutstanding и, согласно рекомендациям VMware, должна быть эквивалентна ей. Если эти значения различаются, то когда несколько ВМ используют с хоста ESXi один LUN - актуальной длиной очереди считается минимальное из этих значений.

Для отслеживания текущих значений очередей можно использовать утилиту esxtop, как описано в KB 1027901.

Как мы уже писали недавно, в VMware vSphere есть политика путей, называемая Fixed path with Array Preference (в интерфейсе vSphere Client 4.1 она называется VMW_PSP_FIXED_AP). По умолчанию она выбирается для дисковых массивов, которые поддерживают ALUA. Эта политика опрашивает дисковый массив (A-A или A-P), позволяя ему самому определить, какие пути использовать как preferred path, если это не указано пользователем...

Некоторое время назад мы уже писали о возможности конвертации RDM-томов, работающих в режиме виртуальной и физической совместимости, в формат VMDK. Сегодня мы поговорим об обратном преобразовании: из формата VMDK в формат RDM (physical RDM или virtual RDM).

Для начала опробуйте все описанное ниже на тестовой виртуальной машине, а потом уже приступайте к продуктивной. Перед началом конвертации необходимо остановить ВМ, а также сделать remove виртуального диска из списка устройств виртуальной машины. Определите, какой режим совместимости диска RDM вам необходим (pRDM или vRDM), прочитав нашу статью "Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere".

Создайте новый LUN на дисковом массиве, где будет размещаться RDM-том, и сделайте Rescan на хосте ESXi, чтобы увидеть добавленный девайс в vSphere Client:

Обратите внимание на Runtime Name (в данном случае vmhba37:C0:T1:L0) и на идентификатор в скобках (naa.6000eb....итакдалее) - этот идентификатор нам и нужен. Словить его можно, выполнив следующую команду (подробнее об идентификации дисков тут):

# esxcfg-mpath -L

В результатах вывода по Runtime Name можно узнать идентификатор. Вывод будет примерно таким:

vmhba33:C0:T0:L0 state:active naa.6090a038f0cd6e5165a344460000909b vmhba33 0 0 0 NMP active san iqn.1998-01.com.vmware:bs-tse-i137-35c1bf18 00023d000001,iqn.2001-05.com.equallogic:0-8a0906-516ecdf03-9b9000004644a365-bs-lab-vc40,t,1

Соответственно, второе выделенное жирным - идентификатор, его копируем.

Далее выполняем следующую команду для конвертации диска в Virtual RDM:

# vmkfstools –i <исходный>.vmdk -d rdm:/vmfs/devices/disks/<идентификатор>
/vmfs/volumes/datastore/vmdir/vmname.vmdk

Для Physical RDM:

# vmkfstools –i <исходный>.vmdk -d rdmp:/vmfs/devices/disks/<идентификатор>
/vmfs/volumes/datastore/vmdir/vmname.vmdk

Обратите внимание, что команты отличаются только параметрами rdm (виртуальный) и rdmp (физический).

Здесь:

• <исходный> - это путь к старому VMDK-диску, например, old.vmdk
• <идентификатор> - это то, что мы скопировали
• путь с vmdir - это путь к заголовочному VMDK-файлу для RDM-тома (может быть на любом общем Datastore)

Второй вариант клонирования диска подсказывает нам Иван:

vmkfstools --clonevirtualdisk /vmfs/volumes/Demo-Desktop-01/Exchange1/Exchange1_1.vmdk
/vmfs/volumes/Demo-Desktop-01/Exchange1/Exchange1_1_RDM.vmdk
--diskformat rdmp:/vmfs/devices/disks/naa.60a9800057396d2f685a64346b664549

Далее выберите виртуальную машину в vSphere Client и сделайте Add Disk, где в мастере укажите тип диска RDM и следуйте по шагам мастера для добавления диска. После этого проверьте, что LUN больше не показывается при выборе Add Storage для ESXi в vSphere Client. Запустите виртуальную машину и, если необходимо, в гостевой ОС в оснастке Disk Management сделайте этот диск Online.